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AES Encryption with HMAC-SHA2 for Kerberos 5 


Abstract 


This document specifies two encryption types and two corresponding 
checksum types for Kerberos 5. The new types use AES in CTS mode 
(CBC mode with ciphertext stealing) for confidentiality and HMAC with 
a SHA-2 hash for integrity. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc8009. 
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1. Introduction 


This document defines two encryption types and two corresponding 
checksum types for Kerberos 5 using AES with 128-bit or 256-bit keys. 


To avoid ciphertext expansion, we use a variation of the CBC-CS3 mode 
defined in [SP800-38A+], also referred to as ciphertext stealing or 
CTS mode. The new types conform to the framework specified in 
[RFC3961], but do not use the simplified profile, as the simplified 
profile is not compliant with modern cryptographic best practices 
such as calculating Message Authentication Codes (MACs) over 
ciphertext rather than plaintext. 


The encryption and checksum types defined in this document are 
intended to support environments that desire to use SHA-256 or 
SHA-384 (defined in [FIPS180]) as the hash algorithm. Differences 
between the encryption and checksum types defined in this document 
and the pre-existing Kerberos AES encryption and checksum types 
Specified in [RFC3962] are: 


* The pseudorandom function (PRF) used by PBKDF2 is HMAC-SHA-256 or 
HMAC-SHA-384. (HMAC is defined in [RFC2104].) 


* A key derivation function from [SP800-108] using the SHA-256 or 


SHA-384 hash algorithm is used to produce keys for encryption, 
integrity protection, and checksum operations. 
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* The HMAC is calculated over the cipher state concatenated with the 
AES output, instead of being calculated over the confounder and 
plaintext. This allows the message receiver to verify the 
integrity of the message before decrypting the message. 


* The HMAC algorithm uses the SHA-256 or SHA-384 hash algorithm for 
integrity protection and checksum operations. 


Protocol Key Representation 

The AES key space is dense, so we can use random or pseudorandom 
octet strings directly as keys. The byte representation for the key 
is described in [FIPS197], where the first bit of the bit string is 
the high bit of the first byte of the byte string (octet string). 


Key Derivation Function 


We use a key derivation function from Section 5.1 of [SP800-108], 
which uses the HMAC algorithm as the PRF. 


function KDF-HMAC-SHA2 (key, label, [context,] k): 
k-truncate (K1) 


where the value of K1 is computed as below. 


key: The source of entropy from which subsequent keys are derived. 
(This is known as "Ki" in [SP800-108].) 


label: An octet string describing the intended usage of the derived 
key. 


context: This parameter is optional. An octet string containing the 
information related to the derived keying material. This 
Specification does not dictate a specific format for the context 
field. The context field is only used by the pseudorandom function 
defined in Section 5, where it is set to the pseudorandom function's 
octet-string input parameter. The content of the octet-string input 
parameter is defined by the application that uses it. 


k: Length in bits of the key to be outputted, expressed in big-endian 
binary representation in 4 bytes. (This is called "L" in 
[SP800-108].) Specifically, k-128 is represented as 0x00000080, 192 
as 0x000000C0, 256 as 0x00000100, and 384 as 0x00000180. 


When the encryption type is aes128-cts-hmac-sha256-128, k must be no 
greater than 256 bits. When the encryption type is 
aes256-cts-hmac-sha384-192, k must be no greater than 384 bits. 
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The k-truncate function is defined in Section 5.1 of [RFC3961]. It 
returns the 'k' leftmost bits of the bit-string input. 


In all computations in this document, STER indicates concatenation. 


When the encryption type is aes128-cts-hmac-sha256-128, then Kl is 
computed as follows: 


If the context parameter is not present: 
Kl = HMAC-SHA-256 (key, 0x00000001 | label | 0x00 | k) 


If the context parameter is present: 
K1 = HMAC-SHA-256 (key, 0x00000001 | label | 0x00 | context | k) 


When the encryption type is aes256-cts-hmac-sha384-192, then K1 is 
computed as follows: 


If the context parameter is not present: 
Kl = HMAC-SHA-384(key, 0x00000001 | label | 0x00 | k) 


If the context parameter is present: 
Kl = HMAC-SHA-384(key, 0x00000001 | label | 0x00 | context | k) 


In the definitions of K1 above, '0x00000001' is the i parameter (the 
iteration counter) from Section 5.1 of [SP800-108]. 


4. Key Generation from Pass Phrases 


As defined below, the string-to-key function uses PBKDF2 [RFC2898] 
and KDF-HMAC-SHA2 to derive the base-key from a passphrase and salt. 
The string-to-key parameter string is 4 octets indicating an unsigned 
number in big-endian order, consistent with [RFC3962], except that 
the default is decimal 32768 if the parameter is not specified. 


To ensure that different long-term base-keys are used with different 
enctypes, we prepend the enctype name to the salt, separated by a 
null byte. The enctype-name is "aes128-cts-hmac-sha256-128" or 
"aes256-cts-hmac-sha384-192" (without the quotes). 
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The user's long-term base-key is derived as follows: 


iter count = string-to-key parameter, default is decimal 32768 
saltp = enctype-name | 0x00 | salt 
tkey = random-to-key (PBKDF2 (passphrase, saltp, 
iter count, keylength)) 
base-key = random-to-key (KDF-HMAC-SHA2 (tkey, "kerberos", 
keylength)) 


where "kerberos" is the octet-string 0x6B65726265726F73. 


where PBKDF2 is the function of that name from RFC 2898, the 
pseudorandom function used by PBKDF2 is HMAC-SHA-256 when the enctype 
is "aes128-cts-hmac-sha256-128" and HMAC-SHA-384 when the enctype is 
"aes256-cts-hmac-sha384-192", the value for keylength is the AES key 
length (128 or 256 bits), and the algorithm KDF-HMAC-SHA2 is defined 
in Section 3. 


5. Kerberos Algorithm Protocol Parameters 


The cipher state defined in RFC 3961 that maintains cryptographic 
state across different encryption operations using the same key is 
used as the formal initialization vector (IV) input into CBC-CS3. 
The plaintext is prepended with a 16-octet random value generated by 
the message originator, known as a confounder. 


The ciphertext is a concatenation of the output of AES in CBC-CS3 
mode and the HMAC of the cipher state concatenated with the AES 
output. The HMAC is computed using either SHA-256 or SHA-384 
depending on the encryption type. The output of HMAC-SHA-256 is 
truncated to 128 bits, and the output of HMAC-SHA-384 is truncated to 
192 bits. Sample test vectors are given in Appendix A. 


Decryption is performed by removing the HMAC, verifying the HMAC 
against the cipher state concatenated with the ciphertext, and then 
decrypting the ciphertext if the HMAC is correct. Finally, the first 
16 octets of the decryption output (the confounder) is discarded, and 
the remainder is returned as the plaintext decryption output. 


The following parameters apply to the encryption types 
aes128-cts-hmac-sha256-128 and aes256-cts-hmac-sha384-192. 


protocol key format: as defined in Section 2. 
Specific key structure: three derived keys: { Kc, Ke, Ki }. 


Kc: the checksum key, inputted into HMAC to provide the checksum 
mechanism defined in Section 6. 
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Ke: the encryption key, inputted into AES encryption and decryption 
as defined in "encryption function" and "decryption function" below. 


Ki: the integrity key, inputted into HMAC to provide authenticated 
encryption as defined in "encryption function" and "decryption 
function" below. 

required checksum mechanism: as defined in Section 6. 
key-generation seed length: key size (128 or 256 bits). 
string-to-key function: as defined in Section 4. 

default string-to-key parameters: iteration count of decimal 32768. 


random-to-key function: identity function. 


key-derivation function: KDF-HMAC-SHA2 as defined in Section 3. The 
key usage number is expressed as 4 octets in big-endian order. 


If the enctype is aes128-cts-hmac-sha256-128: 

Kc = KDF-HMAC-SHA2 (base-key, usage 0x99, 128) 
Ke = KDF-HMAC-SHA2 (base-key, usage OxAA, 128) 
Ki = KDF-HMAC-SHA2 (base-key, usage | 0x55, 128) 


If the enctype is aes256-cts-hmac-sha384-192: 


Kc = KDF-HMAC-SHA2 (base-key, usage | 0x99, 192) 
Ke = KDF-HMAC-SHA2 (base-key, usage OxAA, 256) 
Ki = KDF-HMAC-SHA2 (base-key, usage 0x55, 192) 


cipher state: a 128-bit CBC initialization vector derived from a 
previous ciphertext (if any) using the same encryption key, as 
Specified below. 


initial cipher state: all bits zero. 

encryption function: as follows, where E() is AES encryption in 
CBC-CS3 mode, and h is the size of truncated HMAC (128 bits or 192 
bits as described above). 


N = random value of length 128 bits (the AES block size) 
IV = cipher state 

C = E(Ke, N | plaintext, IV) 

H = HMAC(Ki, IV | C) 

ciphertext = C | H[1..h] 
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Steps to compute the 128-bit cipher state: 
L = length of C in bits 


portion C into 128-bit blocks, placing any remainder of less 


than 128 bits into a final block 
if L == 128: cipher state = C 


else if L mod 128 » 0: cipher state - last full (128-bit) block 


of C (the next-to-last 
block) 


else if L mod 128 == 0: cipher state - next-to-last block of C 


(Note that L will never be less than 128 because of the 
presence of N in the encryption input.) 


decryption function: as follows, where D() is AES decryption in 
CBC-CS3 mode, and h is the size of truncated HMAC. 


(C, H) = ciphertext 
(Note: H is the last h bits of the ciphertext.) 
IV = cipher state 


if H != HMAC(Ki, IV | C)[1..h] 
stop, report error 
(N, P) = D(Ke, C, IV) 


(Note: N is set to the first block of the decryption output; 
set to the rest of the output.) 


cipher state = same as described above in encryption function 
pseudorandom function: 

If the enctype is aes128-cts-hmac-sha256-128: 

PRF = KDF-HMAC-SHA2 (input-key, "prf", octet-string, 256) 


If the enctype is aes256-cts-hmac-sha384-192: 
PRF = KDF-HMAC-SHA2 (input-key, "prf", octet-string, 384) 


where "prf" is the octet-string 0x707266 
6. Checksum Parameters 
The following parameters apply to the checksum types 
hmac-sha256-128-aes128 and hmac-sha384-192-aes256, which are the 
associated checksums for aes128-cts-hmac-sha256-128 and 


aes256-cts-hmac-sha384-192, respectively. 


associated cryptosystem: aes128-cts-hmac-sha256-128 or 
aes256-cts-hmac-sha384-192 as appropriate. 
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get mic: HMAC (Kc, message)[1..h]. 
where h is 128 bits for checksum type hmac-sha256-128-aes128 and 
192 bits for checksum type hmac-sha384-192-aes256 

verify mic: get mic and compare. 


7. IANA Considerations 


IANA has assigned encryption type numbers as follows in the "Kerberos 
Encryption Type Numbers" registry. 


etype encryption type Reference 
19 aes128-cts-hmac-sha256-128 RFC 8009 
20 aes256-cts-hmac-sha384-192 RFC 8009 


IANA has assigned checksum type numbers as follows in the "Kerberos 
Checksum Type Numbers" registry. 


sumtype Checksum type checksum Reference 

value size 

19 hmac-sha256-128-aes128 16 RFC 8009 

20 hmac-sha384-192-aes256 24 RFC 8009 
8. Security Considerations 


This specification requires implementations to generate random 
values. The use of inadequate pseudorandom number generators (PRNGs) 
can result in little or no security. The generation of quality 
random numbers is difficult. [RFC4086] offers guidance on random 
number generation. 


This document specifies a mechanism for generating keys from 
passphrases or passwords. The use of PBKDF2, a salt, and a large 
iteration count adds some resistance to offline dictionary attacks by 
passive eavesdroppers. Salting prevents "rainbow table" attacks, 
while large iteration counts slow password-guess attempts. 
Nonetheless, computing power continues to rapidly improve, including 
the potential for use of graphics processing units (GPUs) in 
password-guess attempts. It is important to choose strong 
passphrases. Use of Kerberos extensions that protect against offline 
dictionary attacks should also be considered, as should the use of 
public key cryptography for initial Kerberos authentication [RFC4556] 
to eliminate the use of passwords or passphrases within the Kerberos 
protocol. 
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The NIST guidance in Section 5.3 of [SP800-38A], requiring that CBC 
initialization vectors be unpredictable, is satisfied by the use of a 
random confounder as the first block of plaintext. The confounder 
fills the cryptographic role typically played by an initialization 
vector. This approach was chosen to align with other Kerberos 
cryptosystem approaches. 


8.1. Random Values in Salt Strings 
The NIST guidance in Section 5.1 of [SP800-132] requires at least 128 


bits of the salt to be randomly generated. The string-to-key 
function as defined in [RFC3961] requires the salt to be valid UTF-8 


strings [RFC3629]. Not every 128-bit random string will be valid 
UTF-8, so a UTF-8-compatible encoding would be needed to encapsulate 
the random bits. However, using a salt containing a random portion 


may have the following issues with some implementations: 


* Keys for cross-realm krbtgt services [RFC4120] are typically 
managed by entering the same password at two Key Distribution 
Centers (KDCs) to get the same keys. If each KDC uses a random 
salt, they won't have the same keys. 


* Random salts may interfere with checking of password history. 
8.2. Algorithm Rationale 


This document has been written to be consistent with common 
implementations of AES and SHA-2. The encryption and hash algorithm 
Sizes have been chosen to create a consistent level of protection, 
with consideration to implementation efficiencies. So, for instance, 
SHA-384, which would normally be matched to AES-192, is instead 
matched to AES-256 to leverage the fact that there are efficient 
hardware implementations of AES-256. Note that, as indicated by the 
enc-type name "aes256-cts-hmac-sha384-192", the truncation of the 
HMAC-SHA-384 output to 192 bits results in an overall 192-bit level 
of security. 
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AES-CTS HMAC-SHA2 For Kerberos 5 


A. Test Vectors 


Sample results for string-to-key conversion: 


Iteration count - 32768 
Pass phrase - "password" 


Saltp 
61 
ES: 
E5 
41 


for creating 128-bit 
65 73 31 32 38 2D 63 
68 61 32 35 36 2D 31 
BC 8A CE A1 73 OE 74 
2E 4D 49 54 2E 45 44 


base-key: 


74 
32 
35 
55 


73 2D 
38 00 
5F 61 
72 61 


68 6D 61 
10 DF 9D 
41 54 48 
65 62 75 


(The saltp is "aes128-cts-hmac-sha256-128" | 
random 16-byte valid UTF-8 sequence | "ATHENA.MIT.EDUraeburn") 
128-bit base-key: 


08 


Saltp 
61 
73 
E5 
41 


9B CA 48 B1 05 EA 6E 


for creating 256-bit 
65 73 32 35 36 2D 63 
68 61 33 38 34 2D 31 
BC 8A CE A1 73 OE 74 
2E 4D 49 54 2E 45 44 


63 2D 
D7 83 
45 4E 
72 6E 


0x00 | 


A7 7C A5 D2 F3 9D C5 E7 


base-key: 


74 
39 
35 
33 


73 2D 
32 00 
5F 61 
72 61 


68 6D 61 
10 DF 9D 
41 54 48 
65 62 75 


(The saltp is "aes256-cts-hmac-sha384-192" | 
random 16-byte valid UTF-8 sequence | "ATHENA.MIT.EDUraeburn") 

256-bit base-key: 
45 BD 80 6D BF 6A 83 3A 9C FF C1C9 45 89 A2 22 


36 7A 79 BC 21 C4 13 71 89 06 
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D7 83 
45 4E 
72 6E 
0x00 | 


E9 F5 78 A7 84 67 


October 2016 


[Page 12] 


RFC 8009 


AES-CTS HMAC-SHA2 For Kerberos 


Sample results for key derivation: 


enctype aes128-cts-hmac-sha256-128: 
128-bit base-key: 


37 05 
Kc value 
B3 1A 
Ke value 
9B 19 
Ki value 
9F DA 


D9 60 80 C1 77 28 A0 E8 00 EA B6 EO D2 


for key usage 2 (label = 0x0000000299): 


01 8A 48 F5 47 76 F4 03 E9 A3 96 32 5D 


for key usage 2 (label = 0x00000002AA) : 


7D D1 E8 C5 60 9D 6E 67 C3 E3 7C 62 C7 


for key usage 2 (label = 0x0000000255): 


OE 56 AB 2D 85 El 56 9A 68 86 96 C2 6A 


enctype aes256-cts-hmac-sha384-192: 
256-bit base-key: 


6D 40 
00 EB 
Kc value 
EF 57 
BA 41 
Ke value 
56 AB 
A5 EB 
Ki value 
69 B1 
22 C4 


Jenkins, et 


4D 37 FA F7 9F 9D FO D3 35 68 D3 20 66 
48 36 47 2E A8 AO 26 D1 6B 71 82 46 OC 


for key usage 2 (label = 0x0000000299): 


18 BE 86 CC 84 96 3D 8B BB 50 31 E9 F5 
F2 8F AF 69 E7 3D 


for key usage 2 (label = 0x00000002AA): 


22 BE E6 3D 82 D7 BC 52 27 F6 77 3F 8E 
1C 82 51 60 C3 83 12 98 OC 44 2E 5C 7E 


for key usage 2 (label = 0x0000000255): 


65 14 E3 CD 8E 56 B8 20 10 D5 C7 30 12 
DO OF FC 23 ED 1F 


al. Informational 


5 


October 2016 


[Page 13] 


RFC 8009 


Sample encrypti 
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ons (all using the default cipher state): 


These sample encryptions use the above 


including use of the same base-key and 


The following test vectors are for 
enctype aes128-cts-hmac-sha256-128: 


Plaintext: (emp 
Confounder: 


ty) 


7E 58 95 EA F2 67 24 35 


128-bit AES key 


(Ke): 


9B 19 7D D1 E8 C5 60 9D 


128-bit HMAC ke 


y (Ki): 


9F DA OE 56 AB 2D 85 El 


AES Output: 
EF 85 FB 89 
Truncated HMAC 
AD 87 7E DA 


OB B8 47 
Output: 
39 D5 OC 


2F 


87 


BA 


6E 


56 


4D 


oc 


Ciphertext (AES Output | HMAC 
0B B8 47 2F 4D 


EF 85 FB 89 
AD 87 7E DA 


Plaintext: (len 

00 01 02 03 
Confounder: 

7B CA 28 5E 
128-bit AES key 

9B 19 7D D1 
128-bit HMAC ke 

9F DA OE 56 
AES Output: 

84 D7 F3 07 

B5 54 02 CE 
Truncated HMAC 

87 7C E9 9E 
Ciphertext: 

84 D7 F3 07 
B5 54 02 CE 
42 1D FD F8 
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39 D5 OC 


gth less 
04 05 


2F D4 13 
(Ke): 
E8 C5 60 
y (Ki): 
AB 2D 85 


54 ED 98 
F7 E6 
Output: 
24 7E 52 


54 ED 98 
F7 E6 87 
97 6C 


87 


oc 


D8 17 F5 


67 C3 E3 


9A 68 86 


AB 20 39 
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sample key derivation results, 


key usage values. 


45 


7C 


96 


4D 


8E 


4D 
8E 


than block size) 


OF 


9D 


El 


7B 


D1 


7B 
7C 


B5 


6E 


E9 


5B 


67 


9A 


0B 


D4 


OB 
9E 


1A 


c3 


68 


F3 


42 


F3 
24 


5C 


E3 


86 


50 


1D 


50 
7E 


83 


7C 


96 


6B 


FD 


6B 
52 


Informational 


A3 


62 


C2 


CA 


48 


CA 
48 


BC 


62 


C2 


EB 


F8 


EB 
D1 


71 


C7 


6A 


78 


C7 


78 
C7 


5B 


C7 


6A 


09 


97 


09 
6E 


48 


2E 


6C 


1D 


18 


1D 
18 


24 


2E 


6C 


CF 


6C 


CF 
D4 


[Page 14] 


RFC 8009 AES-CTS HMAC-SHA2 For Kerberos 5 October 2016 


Plaintext: (length equals block size) 

00 01 02 03 04 05 06 07 08 09 OA OB OC OD OE OF 
Confounder: 

56 AB 21 71 3F F6 2C OA 14 57 20 OF 6F A9 94 8F 
128-bit AES key (Ke): 

9B 19 7D D1 E8 C5 60 9D 6E 67 C3 E3 7C 62 C7 2E 
128-bit HMAC key (Ki): 

9F DA OE 56 AB 2D 85 El 56 9A 68 86 96 C2 6A 6C 
AES Output: 

35 17 D6 40 F5 OD DC 8A D3 62 87 22 B3 56 9D 2A 

EO 74 93 FA 82 63 25 40 80 EA 65 C1 00 8E 8F C2 
Truncated HMAC Output: 

95 FB 48 52 E7 D8 3E 1E 7C 48 C3 7E EB E6 BO D3 
Ciphertext: 

35 17 D6 40 F5 OD DC 8A D3 62 87 22 B3 56 9D 2A 

EO 74 93 FA 82 63 25 40 80 EA 65 C1 00 8E 8F C2 

95 FB 48 52 E7 D8 3E 1E 7C 48 C3 7E EB E6 BO D3 


Plaintext: (length greater than block size) 
00 01 02 03 04 05 06 07 08 09 OA OB OC OD OE OF 
10-11 12-13 14 
Confounder: 
A7 A4 E2 9A 47 28 CE 10 66 4F B6 4E 49 AD 3F AC 
128-bit AES key (Ke): 
9B 19 7D D1 E8 C5 60 9D 6E 67 C3 E3 7C 62 C7 2E 
128-bit HMAC key (Ki): 
9F DA OE 56 AB 2D 85 El 56 9A 68 86 96 C2 6A 6C 
AES Output: 
72 OF 73 B1 8D 98 59 CD 6C CB 43 46 11 5C D3 36 
C7 OF 58 ED CO C4 43 7C 55 73 54 4C 31 C8 13 BC 
El E6 DO 72 C1 
Truncated HMAC Output: 
86 B3 9A 41 3C 2F 92 CA 9B 83 34 A2 87 FF CB FC 
Ciphertext: 
72 OF 73 B1 8D 98 59 CD 6C CB 43 46 11 5C D3 36 
C7 OF 58 ED CO C4 43 7C 55 73 54 4C 31 C8 13 BC 
El E6 DO 72 C1 86 B3 9A 41 3C 2F 92 CA 9B 83 34 
A2 87 FF CB FC 
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The following test vectors are for enctype 
aes256-cts-hmac-sha384-192: 


Plaintext: (empty) 
Confounder: 
F7 64 E9 FA 15 C2 76 47 8B 2C 7D OC 4E 5F 58 E4 
256-bit AES key (Ke): 
56 AB 22 BE E6 3D 82 D7 BC 52 27 F6 77 3F 8E A7 
A5 EB 1C 82 51 60 C3 83 12 98 OC 44 2E 5C 7E 49 
192-bit HMAC key (Ki): 
69 B1 65 14 E3 CD 8E 56 B8 20 10 D5 C7 30 12 B6 
22 C4 DO OF FC 23 ED 1F 
AES Output: 
41 F5 3F A5 BF E7 02 6D 91 FA F9 BE 95 91 95 AO 
Truncated HMAC Output: 
58 70 72 73 A9 6A 40 FO AO 19 60 62 1A C6 12 74 
8B 9B BF BE 7E B4 CE 3C 
Ciphertext: 
41 F5 3F A5 BF E7 02 6D 91 FA F9 BE 95 91 95 AO 
58 70 72 73 A9 6A 40 FO AO 19 60 62 1A C6 12 74 
8B 9B BF BE 7E B4 CE 3C 


Plaintext: (length less than block size) 
00 01 02 03 04 05 
Confounder: 
B8 0D 32 51 C1 F6 47 14 94 25 6F FE 71 2D OB 9A 
256-bit AES key (Ke): 
56 AB 22 BE E6 3D 82 D7 BC 52 27 F6 77 3F 8E A7 
A5 EB 1C 82 51 60 C3 83 12 98 OC 44 2E 5C 7E 49 
192-bit HMAC key (Ki): 
69 B1 65 14 E3 CD 8E 56 B8 20 10 D5 C7 30 12 B6 
22 C4 DO OF FC 23 ED 1F 
AES Output: 
4E D7 B3 7C 2B CA C8 F7 4F 23 Cl CF 07 E6 2B C7 
B7 5F B3 F6 37 B9 
Truncated HMAC Output: 
F5 59 C7 F6 64 F6 9E AB 7B 60 92 23 75 26 EA OD 
1F 61 CB 20 D6 9D 10 F2 
Ciphertext: 
4E D7 B3 7C 2B CA C8 F7 4F 23 Cl CF 07 E6 2B C7 
B7 5F B3 F6 37 B9 F5 59 C7 F6 64 F6 9E AB 7B 60 
92 23 75 26 EA OD 1F 61 CB 20 D6 9D 10 F2 
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Plaintext: (length equals block size) 
00 01 02 03 04 05 06 07 08 09 OA OB OC OD OE OF 
Confounder: 
53 BF 8A OD 10 52 65 D4 E2 76 42 86 24 CE 5E 63 
256-bit AES key (Ke): 
56 AB 22 BE E6 3D 82 D7 BC 52 27 F6 77 3F 8E A7 
A5 EB 1C 82 51 60 C3 83 12 98 OC 44 2E 5C 7E 49 
192-bit HMAC key (Ki): 
69 B1 65 14 E3 CD 8E 56 B8 20 10 D5 C7 30 12 B6 
22 C4 DO OF FC 23 ED 1F 
AES Output: 
BC 47 FF EC 79 98 EB 91 E8 
BB E2 E1 63 E8 7D D3 7F 49 
Truncated HMAC Output: 
8C F5 1F 14 D7 98 C2 27 3F 35 DF 57 4D 1F 93 2E 
40 CA FF 25 5B 36 A2 66 
Ciphertext: 
BC 47 FF EC 79 98 EB 91 E8 11 5C F8 D1 9D AC 4B 
BB E2 El 63 E8 7D D3 7F 49 BE CA 92 02 77 64 F6 
8C F5 IF 14 D7 98 C2 27 3F 35 DF 57 4D 1F 93 2E 
40 CA FF 25 5B 36 A2 66 


1 5C F8 D1 9D AC 4B 
E CA 92 02 77 64 F6 


W e 


Plaintext: (length greater than block size) 
00 01 02 03 04 05 06 07 08 09 OA OB OC OD OE OF 
LO: TL 12 13 14 

Confounder: 
76 3E 65 36 7E 86 4F 02 F5 51 53 C7 E3 B5 8A F1 

256-bit AES key (Ke): 
56 AB 22 BE E6 3D 82 D7 BC 52 27 F6 77 3F 8E A7 
A5 EB 1C 82 51 60 C3 83 12 98 OC 44 2E 5C 7E 49 

192-bit HMAC key (Ki): 
69 Bl 65 14 E3 CD 8E 56 B8 20 10 D5 C7 30 12 B6 
22 C4 DO OF FC 23 ED 1F 

AES Output: 
40 01 3E 2D F5 8E 87 51 95 7D 28 78 BC D2 D6 FE 
10 1C CF D5 56 CB 1E AE 79 DB 3C 3E E8 64 29 F2 
B2 A6 02 AC 86 

Truncated HMAC Output: 
FE F6 EC B6 47 D6 29 5F AE 07 7A 1F EB 51 75 08 
D2 Cl 6B 41 92 EO 1F 62 

Ciphertext: 
40 01 3E 2D F5 8E 87 51 95 7D 28 78 BC D2 D6 FE 
10 1C CF D5 56 CB 1E AE 79 DB 3C 3E E8 64 29 F2 
B2 A6 02 AC 86 FE F6 EC B6 47 D6 29 5F AE 07 7A 
1F EB 51 75 08 D2 C1 6B 41 92 EO 1F 62 
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October 2016 


These sample checksums use the above sample key derivation results, 


including use of the same base-key and key usage values. 


Checksum type: 
128-bit HMAC key 
8A 48 F5 47 76 F4 03 E9 A3 96 


B3 1A 01 
Plaintext: 
00 01 02 
TO T1 2 
Checksum: 
D7 83 67 


hmac-sha256-128-aes128 


(Kc): 


03 04 05 06 07 08 09 OA OB OC 


13 


14 


18 66 43 D6 7B 41 1C BA 91 39 


Checksum type: 
192-bit HMAC key 


EF 57 18 
BA 41 F2 
Plaintext: 
00 01 02 
TO 11.12 
Checksum: 
45 EE 79 
43 C3 BF 


Jenkins, et al. 


BE 
8F 


03 
13 


15 
AO 


hmac-sha384-192-aes256 


86 
AF 


04 
14 


67 
66 


(Kc): 
CC 84 96 
69 E7 3D 


05 06 07 


EE FC A3 
99 67 2A 


3D 8B BB 50 31 


08 09 OA OB OC 


7F 4A C1 EO 22 


Informational 


32 


OD 


FC 


E9 


OD 


2D 


5D 


OE 


1D 


F5 


OE 


E8 


C3 


OF 


EE 


C4 


OF 


OD 
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Sample pseudorandom function (PRF) invocations: 


PRF input octet-string: "test" (0x74657374) 


enctype aes128-cts-hmac-sha256-128: 
input-key value / HMAC-SHA-256 key: 
37 05 D9 60 80 C1 77 28 AO E8 00 EA B6 EO D2 3C 
HMAC-SHA-256 input message: 
00 00 00 01 70 72 66 00 74 65 73 74 00 00 01 00 
PRF output: 
9D 18 86 16 F6 38 52 FE 86 91 5B B8 40 B4 A8 86 
FF 3E 6B BO F8 19 B4 9B 89 33 93 D3 93 85 42 95 


enctype aes256-cts-hmac-sha384-192: 
input-key value / HMAC-SHA-384 key: 
6D 40 4D 37 FA F7 9F 9D FO D3 35 68 D3 20 66 98 
00 EB 48 36 47 2E A8 AO 26 D1 6B 71 82 46 OC 52 
HMAC-SHA-384 input message: 
00 00 00 01 70 72 66 00 74 65 73 74 00 00 01 80 
PRF output: 
98 01 F6 9A 36 8C 2B F6 75 E5 95 21 El 77 D9 AO 
TE 67 EF El CF DE 8D 3C 8D 6F 6A 02 56 E3 B1 7D 
B3 C1 B6 2A D1 B8 55 33 60 D1 73 67 EB 15 14 D2 
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